<html>
<head><meta charset="utf-8"><title>Language UB vs library UB · t-lang/wg-unsafe-code-guidelines · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/index.html">t-lang/wg-unsafe-code-guidelines</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html">Language UB vs library UB</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="204077920"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204077920" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204077920">(Jul 16 2020 at 12:49)</a>:</h4>
<p>The <a href="https://internals.rust-lang.org/t/why-even-unused-data-needs-to-be-valid/12734">discussion following my recent blog post</a> is mostly about people being very confused about the distinction between validity invariant ("language invariant") and safety invariant ("library invariant"), and between language UB and library UB. We really need better terminology, so that we can start fixing all the docs to use that terminology consistently.</p>



<a name="204078327"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204078327" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204078327">(Jul 16 2020 at 12:53)</a>:</h4>
<p>I also recall <span class="user-mention" data-user-id="239881">@Josh Triplett</span> suggesting we should avoid "UB" entirely as it is a burnt term at least for some people with a C/C++ background. On the other hand, it does have the right meaning. On yet another hand it would be nice to have a positive term for "program whose behavior complies with compiler expectations", and maybe "program that satisfies library contract", instead of a negative one (like "UB-free")</p>



<a name="204079240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204079240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lzutao <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204079240">(Jul 16 2020 at 13:01)</a>:</h4>
<p>It maybe a "burnt" term but at least it is wide-spread and concise.</p>



<a name="204079895"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204079895" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204079895">(Jul 16 2020 at 13:06)</a>:</h4>
<p>I am also unsure if we want the terms for "language UB" and "library UB" to be similar (to demonstrate the parallels) or as different as possible (to avoid confusion between these two concepts).</p>



<a name="204097069"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204097069" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204097069">(Jul 16 2020 at 15:10)</a>:</h4>
<p>I mentioned it on that post, but the general term of Undefined Behaviour is just that. It's not a term which rust should reserve for itself. Language UB (or likewise Language Level UB, or Core Language UB) certainly could (there is precedent to do so).<br>
Abandoning the term is honestly not a good idea in my opinion. It has connotations which no other term really possesses (anyone heard of Nasal Demons).</p>



<a name="204097877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204097877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204097877">(Jul 16 2020 at 15:16)</a>:</h4>
<p>For a positive term, the term "Correct" is one I frequently associate with not having any compile-time errors (IE. well-formed or not ill-formed), and that doesn't evaluate a construct which has undefined behaviour. That could be adopted.</p>



<a name="204098851"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204098851" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204098851">(Jul 16 2020 at 15:23)</a>:</h4>
<p>I think that "language invariant" and "library invariant" remain a very poor pairing of terms exactly because they have the same initials.</p>



<a name="204111030"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204111030" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204111030">(Jul 16 2020 at 16:50)</a>:</h4>
<p>it works if abbreviated as LangI and LibI</p>



<a name="204118812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204118812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204118812">(Jul 16 2020 at 17:53)</a>:</h4>
<p>Still too close. There's a lot of English words, we can pick ones that aren't so close together</p>



<a name="204119462"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204119462" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204119462">(Jul 16 2020 at 17:58)</a>:</h4>
<p>compiler-UB and library-UB?</p>



<a name="204120163"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204120163" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204120163">(Jul 16 2020 at 18:03)</a>:</h4>
<p>that's fine</p>



<a name="204120270"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204120270" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204120270">(Jul 16 2020 at 18:04)</a>:</h4>
<p>I'm a big fan of validity invariant and safety invariant, no reason to not use those</p>



<a name="204154852"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204154852" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Gankra <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204154852">(Jul 16 2020 at 23:18)</a>:</h4>
<p>should definitely try to make them be LUB and GLB just to really make compiler work confusing</p>



<a name="204196690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204196690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204196690">(Jul 17 2020 at 11:50)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204097069">said</a>:</p>
<blockquote>
<p>I mentioned it on that post, but the general term of Undefined Behaviour is just that. It's not a term which rust should reserve for itself. Language UB (or likewise Language Level UB, or Core Language UB) certainly could (there is precedent to do so).<br>
Abandoning the term is honestly not a good idea in my opinion. It has connotations which no other term really possesses (anyone heard of Nasal Demons).</p>
</blockquote>
<p>nobody ever claimed Rust reserves the term for itself. to my knowledge, what we do is entirely consistent with what C/C++ do, including the language UB / library UB distinction. we are just more clear about it.</p>



<a name="204196754"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204196754" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204196754">(Jul 17 2020 at 11:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204098851">said</a>:</p>
<blockquote>
<p>I think that "language invariant" and "library invariant" remain a very poor pairing of terms exactly because they have the same initials.</p>
</blockquote>
<p>fair. I am not a fan of "compiler invariant" though because the compiler is just an implementation of the language spec. miri is another one. this invariant is understood (in different ways) by both.</p>



<a name="204196838"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204196838" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204196838">(Jul 17 2020 at 11:52)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204120270">said</a>:</p>
<blockquote>
<p>I'm a big fan of validity invariant and safety invariant, no reason to not use those</p>
</blockquote>
<p>not to rehash the same old argument again, but the issue with those is that "validity" is way too ambiguous. data violating the asafety invariant is also "invalid" in some sense.</p>



<a name="204200432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204200432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204200432">(Jul 17 2020 at 12:37)</a>:</h4>
<p>I'd honestly argue that keeping a distinction, except in technical documents (such as the reference, and any future language specification), isn't a good idea. It's a great way to get people to justify UB:</p>
<blockquote>
<p>Well it's a safety invariant, so its fine as long as I'm careful</p>
</blockquote>
<p>In my opinion as an api developer, its still UB to violate a safety invariant, the effects are what are deferred. A safety invariant being broken shouldn't magically allow unsoundness, it should be the UB of breaking it in the first place. What happens if a future version implements an optimization, and the safety invariant gets upgrade to a validity invariant. While it is true that knowing the internals of a library makes it less erroneous (I've caused library-level UB in one of my libraries, but I know its fine because I won't break the libraries internal code), its still UB and should be treated as such.</p>



<a name="204200874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204200874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204200874">(Jul 17 2020 at 12:42)</a>:</h4>
<p>what you said IMO is a great argument for clearly communicating the distinction</p>



<a name="204200908"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204200908" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204200908">(Jul 17 2020 at 12:42)</a>:</h4>
<p>because it's just not true that the world will end when you create a non-UTF-8 string. but it <em>is</em> true that the world will end when you transmute 3 to a <code>bool</code>.</p>



<a name="204200960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204200960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204200960">(Jul 17 2020 at 12:43)</a>:</h4>
<p>never did I suggest that we want to use this to allow unsoundness or anything like that</p>



<a name="204200996"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204200996" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204200996">(Jul 17 2020 at 12:43)</a>:</h4>
<p>but we should truthfully communicate what is actually happening, and not paper over the fundamental difference between language UB and library UB</p>



<a name="204201034"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204201034" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204201034">(Jul 17 2020 at 12:44)</a>:</h4>
<blockquote>
<p>What happens if a future version implements an optimization, and the safety invariant gets upgrade to a validity invariant.</p>
</blockquote>
<p>that would be Rust 2.0 territory</p>



<a name="204201095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204201095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204201095">(Jul 17 2020 at 12:44)</a>:</h4>
<p>once we have a proper langauge spec, we can never strengthen the validity invariant. that's the point. the validity invariant / language UB is the bedrock that everything rests on.</p>



<a name="204201113"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204201113" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204201113">(Jul 17 2020 at 12:44)</a>:</h4>
<p>thus we need to be as precise as we can, without scaring away people by using mathematical notation.</p>



<a name="204201296"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204201296" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204201296">(Jul 17 2020 at 12:46)</a>:</h4>
<p>strengthening the validity invariant of Rust would be like strengthening the (clearly documented) safety invariant of a library -- it's a breaking change.</p>



<a name="204201374"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204201374" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204201374">(Jul 17 2020 at 12:48)</a>:</h4>
<blockquote>
<p>, its still UB and should be treated as such.</p>
</blockquote>
<p>you keep saying that. I never said anything else -- it's still <em>library UB</em> and should be treated as such. it's a critical soundness bug, like language UB. but I think for a proper understanding of UB it is important that one is able to appreciate the difference between language UB and library UB.</p>



<a name="204202685"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204202685" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204202685">(Jul 17 2020 at 13:01)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> Where do you see things like <code>String::from_utf8_checked</code> fitting in that? (To be clear; I agree with your distinction)</p>



<a name="204204241"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204204241" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204204241">(Jul 17 2020 at 13:17)</a>:</h4>
<p>that function let's you bypass a check that can prevent library UB. If you call it with <code>&amp;[0xFF]</code> you'll certainly open yourself up to library UB, which is why it's unsafe.</p>



<a name="204205469"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204205469" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204205469">(Jul 17 2020 at 13:28)</a>:</h4>
<blockquote>
<p>not to rehash the same old argument again, but the issue with those is that "validity" is way too ambiguous. data violating the safety invariant is also "invalid" in some sense.</p>
</blockquote>
<p>Several people seem to have a not-fully-accurate view of exactly how the term UB applies as well :3 I think that "we would have to explain our terms" isn't convincing because even as you've been saying lib UB and lang UB this entire time you <em>still</em> are having to explain yourself. I think this has a lot to do with the C/C++ folks not having a clear separation here, but ultimately the reason is unimportant. The <strong>effect</strong> is that we have to explain our terms no matter what terms we pick.</p>
<p>But I spend nearly every day in the Community Discord helping to educate people about unsafe code, and generally a programmer just needs it explained once to understand the validity/safety distinction. After that they may have a question about if a particular bit of UB is from validity invariants or safety invariants, but they never seem to confuse the terms themselves.</p>



<a name="204208914"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204208914" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204208914">(Jul 17 2020 at 13:59)</a>:</h4>
<blockquote>
<p>that is Rust 2.0 territory</p>
</blockquote>
<p>What I meant was a future version of a 3rd party library that documents an invariant, but its not backed by a language-level invariant. By not distinguishing between them, I can in the future upgrade to a language-level invariant so that rust can optimize my code better. Strictly speaking, with a documented distinction, that would be a breaking change (you can produce a value with a broken safety invariant, but you can't use it, as you have mentioned)</p>
<blockquote>
<p>It's still <em>library UB</em> and should be treated as such</p>
</blockquote>
<p>Indeed, and the library reserves the right to do whatever it wants if you violate it, even if it doesn't explicitly cause anything rust itself considers undefined. I can still format your hard drive, print hello world, summon nasal demons or blow up the moon just as much as rust can.   The point is, UB is UB, no matter what level it happens at. In all cases, if you know the implementation won't explode, you can use it just fine, but you have to be a position to forever know that (documented extension, or you writing are the implementation). Beyond that, once you start justifying any UB, you might as well grab a footgun. In my libraries, if I document an invariant, precondition, or other requirement it is immediately undefined behaviour to violate it. </p>
<p>This is why I don't like a distinction. Its undefined behaviour. Full stop.</p>



<a name="204211280"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211280" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211280">(Jul 17 2020 at 14:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219696">XAMPPRocky</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204202685">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> Where do you see things like <code>String::from_utf8_checked</code> fitting in that? (To be clear; I agree with your distinction)</p>
</blockquote>
<p>you mean "unchecked" I assume? violating the precondition is library UB, but on its own there is no lang UB.</p>



<a name="204211339"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211339" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211339">(Jul 17 2020 at 14:21)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> well, "valid" is a general term, that's the confusion. It's "not jargon enough".^^</p>



<a name="204211414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211414">(Jul 17 2020 at 14:21)</a>:</h4>
<blockquote>
<p>What I meant was a future version of a 3rd party library that documents an invariant, but its not backed by a language-level invariant. By not distinguishing between them, I can in the future upgrade to a language-level invariant so that rust can optimize my code better. Strictly speaking, with a documented distinction, that would be a breaking change (you can produce a value with a broken safety invariant, but you can't use it, as you have mentioned)</p>
</blockquote>
<p>library authors may assume their clients do not cause library UB, for the purpose of semver. I see no problem here.</p>



<a name="204211519"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211519" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211519">(Jul 17 2020 at 14:22)</a>:</h4>
<p>The main problem is the way its worded in documentation, its valid to violate a safety invariant, it just may lead to undefined behaviour using it.</p>



<a name="204211714"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211714" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211714">(Jul 17 2020 at 14:24)</a>:</h4>
<blockquote>
<p>This is why I don't like a distinction. Its undefined behaviour. Full stop.</p>
</blockquote>
<p><em>shrug</em> there's not much I can do when you just repeat your same statement in response to each of my arguments.<br>
I wish you good luck explaining to your users why violating the assumptions of your library does not cause an error in <a href="https://github.com/rust-lang/miri/">Miri</a> even when/if Miri reliably detects all UB -- by which of course I mean all language UB, because that is the only UB that exists in the Rust spec. this is one case where the distinction is blatantly obvious. trying to hide it will only cause confusion.</p>
<p>making this distinction might make some folks uncomfortable that are too wed to the fuzzy treatment of UB in C/C++, but I think I can live with that.</p>



<a name="204211812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211812">(Jul 17 2020 at 14:24)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204211519">said</a>:</p>
<blockquote>
<p>The main problem is the way its worded in documentation, its valid to violate a safety invariant, it just may lead to undefined behaviour using it.</p>
</blockquote>
<p>not sure where you quoted that from, but yes this is correct. if your users violate a safety invariant and then <em>never pass that data to your library again</em>, they may rely on nothing going wrong.</p>



<a name="204211889"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211889" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211889">(Jul 17 2020 at 14:25)</a>:</h4>
<p>there was an example of that in the thread (temporarily violating the <code>str</code> safety invariant of UTF-8). no possible update of <code>str</code> can make that code UB.</p>



<a name="204211910"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204211910" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204211910">(Jul 17 2020 at 14:25)</a>:</h4>
<p>so this is yet another argument for making and communicating that distinction.</p>



<a name="204212138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204212138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204212138">(Jul 17 2020 at 14:27)</a>:</h4>
<blockquote>
<p>once you start justifying any UB, you might as well grab a footgun</p>
</blockquote>
<p>indeed there is no justifying of UB. I am sorry if anything I say came across as such.</p>



<a name="204212193"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204212193" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204212193">(Jul 17 2020 at 14:28)</a>:</h4>
<p><code>unsafe</code> Rust is all about flirting with UB but never giving in. that's why it is so important to know exactly where the line goes -- or the lines, as it were.</p>



<a name="204212390"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204212390" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204212390">(Jul 17 2020 at 14:29)</a>:</h4>
<p><a href="https://internals.rust-lang.org/t/why-even-unused-data-needs-to-be-valid/12734/9?u=ralfjung">this example</a> is <em>not</em> library UB, I hope we agree on that? it is certainly not lang UB. but to even explain what happens we need both safety invariant and validity invariant.</p>



<a name="204212789"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204212789" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204212789">(Jul 17 2020 at 14:32)</a>:</h4>
<p>What if I had a type that contains a raw pointer, but it has invariants that it must be valid to dereference, unique, and well-aligned, but I may need to internally break those invariants, so it stays as either a raw pointer or NonNull. Then a future version, I get rid of that. Would it be valid to change it to a reference? Under the rules I've seen its a safety invariant, so changing it to a reference causes undefined behaviour in code that creates the type and does nothing with it. Or would it be a prerequisite to document that something is a Safety Invariant?</p>



<a name="204213318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204213318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204213318">(Jul 17 2020 at 14:36)</a>:</h4>
<p>I dont follow the example. </p>
<blockquote>
<p>but I may need to internally break those invariants</p>
</blockquote>
<p>if you donst distinguish library UB and language UB, this is UB! because UB is UB as you said. so you better dont do this.</p>



<a name="204213399"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204213399" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204213399">(Jul 17 2020 at 14:37)</a>:</h4>
<p>oh no zulip swallowed half my post... at least...</p>



<a name="204214032"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214032" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214032">(Jul 17 2020 at 14:42)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> If you need to upgrade the restrictions on a function or type from being a safety invariant to a validity invariant, that is a breaking change in your semver. You're free to do it, but of course you should clearly explain to the users what's going on and what's different from before.</p>



<a name="204214085"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214085" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214085">(Jul 17 2020 at 14:42)</a>:</h4>
<p>(too many tunnels on this train track...)</p>



<a name="204214165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214165">(Jul 17 2020 at 14:43)</a>:</h4>
<p>I'm allowed to break my libraries internal invariants because I know how to step arround it. Its fragile, but its an implementation detail and I control the invariants. </p>
<blockquote>
<p>If you [are forever in a position] to know the implementation won't explode [its valid] (documented extension <strong>or</strong> you are writing the implementation)</p>
</blockquote>
<p>That rests as the only exception I make to my "don't justify UB rule". Certain types of libraries (in particular, standard libraries) are impossible without causing undefined behaviour. However, in that privileged position, you know how the implementation will respond to the UB, so its valid as long as you are careful. But that <em>only</em> applies to documented extensions or when you are the implementor and can ensure that your internal stuff does not break, but still externally call it UB.</p>



<a name="204214169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214169">(Jul 17 2020 at 14:43)</a>:</h4>
<p>okay so regarding the example -- what is the "that" you get rid of? also, if you didnt document a safety invariant in the first place, I dont understand what you are worried about. people cant just make up a safety invariant and transmute your type around based on that...</p>



<a name="204214264"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214264" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214264">(Jul 17 2020 at 14:44)</a>:</h4>
<blockquote>
<p>I'm allowed to break my libraries internal invariants because I know how to step arround it. Its fragile, but its an implementation detail and I control the invariants. </p>
</blockquote>
<p>you may not do the same with language UB though. so here we have another good reason to distinguish the two.</p>



<a name="204214333"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214333" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214333">(Jul 17 2020 at 14:44)</a>:</h4>
<p>at this point I dont even know what we are disucssing any more, TBH. it seems to have to do with semver (as you keep bringing up situations where you <em>change</em> an existing library), which is rather off-topic.</p>



<a name="204214566"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204214566" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204214566">(Jul 17 2020 at 14:46)</a>:</h4>
<p>That is certainly fair, within libraries themselves they can't internally violate any language invariants, but they also can't internally violate any invariants of dependencies.</p>



<a name="204215559"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204215559" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204215559">(Jul 17 2020 at 14:55)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> So how does the <code>unsafe fn</code> come in with <code>String::from_utf8_unchecked</code>? As in I’ve often heard that <code>unsafe</code> is for language UB and you should not use it for library behaviour.</p>



<a name="204215854"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204215854" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204215854">(Jul 17 2020 at 14:57)</a>:</h4>
<p>Or is it language UB because of <code>str</code>?</p>



<a name="204218480"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204218480" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204218480">(Jul 17 2020 at 15:17)</a>:</h4>
<p>It is <code>unsafe</code>, as violating the contract can cause language UB later on when calling safe methods on the <code>String</code>/<code>&amp;str</code>.</p>



<a name="204221264"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204221264" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204221264">(Jul 17 2020 at 15:39)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219696">XAMPPRocky</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/204215559">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> So how does the <code>unsafe fn</code> come in with <code>String::from_utf8_unchecked</code>? As in I’ve often heard that <code>unsafe</code> is for language UB and you should not use it for library behaviour.</p>
</blockquote>
<p>yeah fair. as <span class="user-mention" data-user-id="133247">@bjorn3</span> said -- if you made it safe, then there would be language UB in safe code by combining from_utf8_unchecked with some other operations.</p>



<a name="204221325"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204221325" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204221325">(Jul 17 2020 at 15:39)</a>:</h4>
<p>so a more precise way to put it would be to say that <code>unsafe</code> is for <em>soundness</em> and not things like memory leaks that are unrrelated to soundness</p>



<a name="204221439"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204221439" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204221439">(Jul 17 2020 at 15:40)</a>:</h4>
<p>but it is the nature of library UB that usually, it exists to avoid underlying language UB. that is the connection here.</p>



<a name="204221440"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/204221440" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#204221440">(Jul 17 2020 at 15:40)</a>:</h4>
<p>soundness is defined as "cannot cause language UB from safe code"</p>



<a name="208194606"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208194606" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208194606">(Aug 27 2020 at 09:27)</a>:</h4>
<p>Some more thinking about this made me realize one thing: the concerns around "library-level UB" are actually very very similar to the concerns around, e.g., relying on unspecified data layout. The current consensus for terminology there (I think) is that exploiting data layout is not on its own UB (if the assumed data layout matches reality), but it could cause UB whenever data layout changes (as e.g. <code>repr(Rust)</code> layout has very few stable guarantees). This is <em>unspecified behavior</em>.<br>
This is a lot like library-level UB, where a large part of the concern is being able to change implementation details of the library without breaking clients. So in that sense it would make more sense to say that violating library contracts leads to <em>unspecified behavior</em>.</p>
<p>Using "Unspecified behavior" in a spec only makes sense when also describing the set of options that the spec may choose from -- e.g., data layout is unspecified, and the set of options is that rustc could pick any possible order, padding and offsets for the fields of a struct. For a library, typically the set of options when the client wanders into the unspecified parts of the API includes language-level UB. For a client of the library, whether an operation is "definitely causing language-level UB" or "unspecified and one of the options is language-level UB" is equivalent, but when one digs a bit deeper into things like we did here, there is a huge difference. I wonder if that is the source of some of the disagreement here about whether or not and if yes how language-UB and "library-UB" should be distinguished.</p>
<p>I also wonder how all of this can help us to find some proper terminology that we can then start applying everywhere...</p>



<a name="208194885"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208194885" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208194885">(Aug 27 2020 at 09:31)</a>:</h4>
<p>It almost seems like the best option is to rename Unspec. Behavior to "Undefined Behavior" (and indeed this is rather close to how UB was used in C originally) and find a different term for "programs that violate fundamental compiler/language expectations", but that would certainly confuse <em>everyone</em> so it's a complete no-go.^^</p>



<a name="208207064"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208207064" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurence Tratt <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208207064">(Aug 27 2020 at 12:03)</a>:</h4>
<p>Terminology is a minefield. I agree that "undefined behaviour" is fixed in people's mind. I recently differentiated the two concepts as "undefined behaviour is guaranteed to never be defined" vs. "behaviour that is currently not defined or which might change". not perfect definitions, and not exactly snappy, but i agree that there is something very important here which can usefully be teased out</p>



<a name="208214942"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208214942" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208214942">(Aug 27 2020 at 13:18)</a>:</h4>
<p>That's not the best definition because everything is UB until it's defined. So if something is UB that's not any assurance that it will always be UB.</p>



<a name="208215615"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208215615" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurence Tratt <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208215615">(Aug 27 2020 at 13:24)</a>:</h4>
<p>some things are (more-or-less) guaranteed to be UB forever; some, as you say, are just UB for now. it can be helpful to know which is which. at the moment we lack the terminology to easily differentiate them</p>



<a name="208364362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364362">(Aug 28 2020 at 16:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/208214942">said</a>:</p>
<blockquote>
<p>That's not the best definition because everything is UB until it's defined. So if something is UB that's not any assurance that it will always be UB.</p>
</blockquote>
<p>No, things are only UB when the spec explicitly says they are.</p>



<a name="208364372"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364372" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364372">(Aug 28 2020 at 16:22)</a>:</h4>
<p>confusingly, "undefined" != "not defined"</p>



<a name="208364389"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364389" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364389">(Aug 28 2020 at 16:23)</a>:</h4>
<p>if the spec doesnt talk about a case, that's a bug in the spec. the spec is incomplete.</p>



<a name="208364465"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364465" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364465">(Aug 28 2020 at 16:23)</a>:</h4>
<p>AFAIK the C spec explicitly says something like "if this spec doesnt cover some case, that case is UB". (so what you say is right for C.) I feel very strongly that Rust should not do this.</p>



<a name="208364524"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364524" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364524">(Aug 28 2020 at 16:24)</a>:</h4>
<p>it's like exhaustiveness checking for <code>match</code> -- when we dont cover a case, that's a bug. we shouldn't have an implicit "UB" fallback.</p>



<a name="208364528"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364528" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364528">(Aug 28 2020 at 16:24)</a>:</h4>
<p>I was just about to say something about this being different in C haha</p>



<a name="208364588"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364588" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364588">(Aug 28 2020 at 16:24)</a>:</h4>
<p>however, "undefined behaviour is guaranteed to never be defined" is not true either <span class="user-mention" data-user-id="252006">@Laurence Tratt</span>  -- future versions of Rust can turn UB into defined behavior.</p>



<a name="208364664"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364664" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364664">(Aug 28 2020 at 16:25)</a>:</h4>
<p><span class="user-mention silent" data-user-id="252006">Laurence Tratt</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/208215615">said</a>:</p>
<blockquote>
<p>some things are (more-or-less) guaranteed to be UB forever; some, as you say, are just UB for now. it can be helpful to know which is which. at the moment we lack the terminology to easily differentiate them</p>
</blockquote>
<p>I don't disagree, but this is not the distinction we are talking about here. so I'd prefer if we would ignore this extra distinction for now to not make things even harder than they already are.^^</p>



<a name="208364754"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208364754" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208364754">(Aug 28 2020 at 16:26)</a>:</h4>
<p>to be clear, the distinction we are talking about here is between what I think is currently usually called language-level UB, language-level <em>unspecified</em> behavior, and library-level UB.</p>



<a name="208366043"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208366043" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurence Tratt <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208366043">(Aug 28 2020 at 16:37)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/208364588">said</a>:</p>
<blockquote>
<p>however, "undefined behaviour is guaranteed to never be defined" is not true either <span class="user-mention silent" data-user-id="252006">Laurence Tratt</span>  -- future versions of Rust can turn UB into defined behavior.</p>
</blockquote>
<p>i agree :) i didn't mean that's what the terms should mean; rather that i needed to differentiate between those two concepts, and lacking any terminology had to resort to <em>something</em>. i'm in agreement with your general plan to tease apart decent meanings</p>



<a name="208408305"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208408305" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208408305">(Aug 29 2020 at 00:39)</a>:</h4>
<blockquote>
<p>confusingly, "undefined" != "not defined"</p>
</blockquote>
<p>Ralf sometimes you make me very, very sad</p>



<a name="208412026"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208412026" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208412026">(Aug 29 2020 at 02:17)</a>:</h4>
<p>Honestly while it might be frustrating from a linguistic point of view, it's an extremely relieving policy to hear, as someone who writes a decent amount of unsafe code</p>



<a name="208412228"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208412228" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208412228">(Aug 29 2020 at 02:22)</a>:</h4>
<p>as someone who also writes quite a bit of unsafe code, i think it provides an additional complexity</p>



<a name="208412248"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208412248" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208412248">(Aug 29 2020 at 02:23)</a>:</h4>
<p>instead of defined/not-defined (which is effectively a bool), we get defined/not-defined/spec-missing (which is an Option&lt;bool&gt;)</p>



<a name="208414538"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208414538" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208414538">(Aug 29 2020 at 03:25)</a>:</h4>
<p>Well you can <code>unwrap_or_default()</code> or file a bug. Probably both.</p>



<a name="208417192"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208417192" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208417192">(Aug 29 2020 at 04:46)</a>:</h4>
<p>anyway part of my enthusiasm here comes from years of frustration with the c++ standard's stance around UB, which is as you state: anything not explicitly defined is UB. in practice this leads to spec bugs being insta-UB, cemented wording choices, and a ton of other really hard to reason about dodginess.</p>
<p>you also end up doing a lot of guessing about what the spec is really saying in some of the particularly dense parts, and trying to figure out "is the reason they said it in this manner intended to explicitly leave something undefined?" in any case where the wording is just a bit weird.</p>



<a name="208425925"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208425925" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208425925">(Aug 29 2020 at 09:40)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/208408305">said</a>:</p>
<blockquote>
<blockquote>
<p>confusingly, "undefined" != "not defined"</p>
</blockquote>
<p>Ralf sometimes you make me very, very sad</p>
</blockquote>
<p>I didn't make up that terminology I am afraid.^^</p>



<a name="208425937"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208425937" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208425937">(Aug 29 2020 at 09:41)</a>:</h4>
<p>I would also think that this helps unsafe code authors, as they no longer have to infer things from <em>absence</em> of inforamtion</p>



<a name="208425986"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language%20UB%20vs%20library%20UB/near/208425986" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB.html#208425986">(Aug 29 2020 at 09:42)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Language.20UB.20vs.20library.20UB/near/208412248">said</a>:</p>
<blockquote>
<p>instead of defined/not-defined (which is effectively a bool), we get defined/not-defined/spec-missing (which is an Option&lt;bool&gt;)</p>
</blockquote>
<p>really you should never run into spec-missing. once we have a spec, that is.^^</p>
<p>this is just like rustc -- you would think you have compiles/compile-error. but no, really you have compiles/compile-error/ICE. the latter is a compiler bug.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>